Skip to content

fix: add count to wait #299

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 4 commits into from
Sep 27, 2024
Merged

fix: add count to wait #299

merged 4 commits into from
Sep 27, 2024

Conversation

@MatthewLemmond
Copy link
Member

Description

If the auth policy creation is skipped, the wait will now also be skipped.
resolves #283

Release required?

  • No release
  • Patch release (x.x.X)
  • Minor release (x.X.x)
  • Major release (X.x.x)
Release notes content

Run the pipeline

If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.

Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:

/run pipeline

Checklist for reviewers

  • If relevant, a test for the change is included or updated with this PR.
  • If relevant, documentation for the change is included or updated with this PR.

For mergers

  • Use a conventional commit message to set the release level. Follow the guidelines.
  • Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
  • Use the Squash and merge option.

@MatthewLemmond
Copy link
Member Author

/run pipeline

ocofaigh
ocofaigh reviewed Sep 26, 2024
View reviewed changes
main.tf Outdated

# workaround for https://github.com/IBM-Cloud/terraform-provider-ibm/issues/4478
resource "time_sleep" "wait_for_authorization_policy" {
count = var.kms_encryption_enabled == false || var.skip_iam_authorization_policy ? 0 : 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if this now has a count, does the depends_on on line 56 need to be updated?

Copy link
Contributor

@ocofaigh ocofaigh Sep 26, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of duplicating line 38 and 48, suggest to use a local (incase the logic is ever updated, it would only need to be changed in 1 place)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if this now has a count, does the depends_on on line 56 need to be updated?

No, when doing depends on we don't do any indexing or anything like that so it passes as is and is still necessary

ocofaigh
ocofaigh requested changes Sep 26, 2024
View reviewed changes
Copy link
Contributor

@ocofaigh ocofaigh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MatthewLemmond Actually the issue you created was to make the change in the DA ->

terraform-ibm-icd-elasticsearch/solutions/standard/main.tf

Lines 59 to 62 in e220b34

resource "time_sleep" "wait_for_authorization_policy" {
depends_on = [ibm_iam_authorization_policy.kms_policy]
create_duration = "30s"
}

The change you made to the module is valid too I guess

@shemau
Copy link
Contributor

shemau commented Sep 26, 2024

It looks like changes are required in both. It seems the DA only creates the policy IF it is cross account. The main module creates the policy if it is the same account.

@MatthewLemmond
Copy link
Member Author

/run pipeline

@MatthewLemmond
Copy link
Member Author

The upgrade test fails due to the wait not being provisioned in the latest version: https://github.com/terraform-ibm-modules/terraform-ibm-icd-elasticsearch/actions/runs/11056038146/job/30716846899#step:7:2206

This is expected because we are now skipping these when an auth policy is not created and the upgrade test uses the standard solution, here is the output doing the upgrade test manually and allowing it to destroy the wait blocks

random_password.admin_password[0]: Refreshing state... [id=none]
module.kms[0].data.ibm_resource_instance.existing_kms_instance[0]: Reading...
module.kms[0].module.kms_key_rings["elasticsearch-key-ring"].ibm_kms_key_rings.key_ring: Refreshing state... [id=elasticsearch-key-ring:keyRing:crn:v1:bluemix:public:hs-crypto:us-south:a/abac0df06b644a9cabc6e44f55b3880e:e6dce284-e80f-46e1-a3c1-830f7adff7a9::]
module.resource_group.data.ibm_resource_group.existing_resource_group[0]: Reading...
module.kms[0].module.kms_keys["elasticsearch-key-ring.elasticsearch-key"].ibm_kms_key.key: Refreshing state... [id=crn:v1:bluemix:public:hs-crypto:us-south:a/abac0df06b644a9cabc6e44f55b3880e:e6dce284-e80f-46e1-a3c1-830f7adff7a9:key:cc0005b9-ef98-4ddb-820c-b74275f30d83]
module.resource_group.data.ibm_resource_group.existing_resource_group[0]: Read complete after 1s [id=c91b01c9dbfa48c3bc5d0571e06d392f]
module.kms[0].data.ibm_resource_instance.existing_kms_instance[0]: Read complete after 2s [id=crn:v1:bluemix:public:hs-crypto:us-south:a/abac0df06b644a9cabc6e44f55b3880e:e6dce284-e80f-46e1-a3c1-830f7adff7a9::]
module.kms[0].module.kms_keys["elasticsearch-key-ring.elasticsearch-key"].ibm_kms_key_policies.root_key_policy[0]: Refreshing state... [id=crn:v1:bluemix:public:hs-crypto:us-south:a/abac0df06b644a9cabc6e44f55b3880e:e6dce284-e80f-46e1-a3c1-830f7adff7a9:key:cc0005b9-ef98-4ddb-820c-b74275f30d83]
module.elasticsearch[0].module.elasticsearch.ibm_iam_authorization_policy.policy[0]: Refreshing state... [id=5e445979-5977-4a8d-a487-02f06a339eef]
module.elasticsearch[0].module.elasticsearch.time_sleep.wait_for_authorization_policy[0]: Refreshing state... [id=2024-09-26T18:45:24Z]
module.elasticsearch[0].module.elasticsearch.ibm_database.elasticsearch: Refreshing state... [id=crn:v1:bluemix:public:databases-for-elasticsearch:us-south:a/abac0df06b644a9cabc6e44f55b3880e:b87fc39a-e6f6-4a57-ab73-09af57be3117::]
module.elasticsearch[0].module.elasticsearch.data.ibm_database_connection.database_connection: Reading...
module.elasticsearch[0].module.elasticsearch.data.ibm_database_connection.database_connection: Read complete after 1s [id=2024-09-26 19:02:27.675321 +0000 UTC]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

The one authorization policy that is still present has its wait still, but the two waits which were not needed have been destroyed. Going to skip the upgrade test for this PR as this all seems to be following the expected behavior of these changes.

@MatthewLemmond
refactor: skipping upgrade test
431f339 
SKIP UPGRADE TEST due to the wait blocks that are not needed being destroyed the upgrade test is failing, this is expected behavior for this update
@MatthewLemmond
Copy link
Member Author

/run pipeline

shemau
shemau approved these changes Sep 27, 2024
View reviewed changes
Copy link
Contributor

@shemau shemau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ocofaigh ocofaigh merged commit f33504f into main Sep 27, 2024
2 checks passed
@ocofaigh ocofaigh deleted the skip-wait branch September 27, 2024 11:17
@terraform-ibm-modules-ops
Copy link
Contributor

🎉 This PR is included in version 1.20.2 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@shemau shemau shemau approved these changes

@ocofaigh ocofaigh ocofaigh approved these changes

@daniel-butler-irl daniel-butler-irl Awaiting requested review from daniel-butler-irl daniel-butler-irl is a code owner

Assignees

No one assigned

Labels

released

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Wait for authorization policies should use count

4 participants

@MatthewLemmond @shemau @terraform-ibm-modules-ops @ocofaigh